ProDataSets and the OpenEdge Reference Architecture
The OpenEdge Reference Architecture represents an effort to formalize the recommended structure of a new or a transformed Progress application, and the reasons for recommending that structure. The remainder of this chapter describes several of the layers of the architecture in more detail. Figure 11–1 shows the high-level layers of the architecture.
In particular, these are the elements of the architecture that pertain to how you use ProDataSets in your application.
The Data Access object discussed in the next section implements the data access layer of the architecture. Its goal is to provide a separation between the physical data in your database or in any other type of data source and the logic that uses that data in the rest of the application. The data itself may be in what we refer to as a managed or unmanaged data store. A managed data store is typically your Progress database or other database you can access through a Progress DataServer. An unmanaged data store could be a set of XML documents, a flat file, a data stream coming from a scanner or other device, or anything else that isn’t a true database.
Typically the ProDataSet represents the internal data definition used by the application. If the data source is in a managed data store, then typically you can define Progress Data-Source objects to specify what tables the data comes from, along with any joins or field mapping that must be done to transfer data to the ProDataSet. If the data source is in an unmanaged data store, then you have to write custom 4GL logic that you use as FILL event procedures for the ProDataSet to define how it is populated. In either case, the overall goal is to make the ultimate source of the data as transparent as possible to the rest of the application.
The Business Entity object is a key part of the implementation of the Business Servicing Layer of the architecture. It can encapsulate one or more ProDataSet definitions that make up a logical application object at the level at which your application typically needs to deal with its data. This might be anything from a single table to a large number of related tables that typically have to be processed together. The Business Entity also includes basic validation logic for its data and an API for all the types of both read and update calls that other objects need to make when they use the object’s data.
Multiple Business Entities together can be used as part of a larger business task or workflow. A Business Entity can also be packaged as a Web Service to be called from outside the Progress environment altogether. A detailed discussion of these uses of Business Entities is beyond the scope of this chapter.
The presentation and integration layers of the architecture can then be defined independently of the business servicing layer, and use the APIs of the Business Entities and other components to retrieve, process, and update data.
The following sections discuss the principles behind each of the components that make up the data access and Business Entity parts of the architecture.